1. Background and Relevant Art
Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, accounting, etc.) that prior to the advent of the computer system were performed manually. More recently, computer systems have been coupled to one another and to other electronic devices to form both wired and wireless computer networks over which the computer systems and other electronic devices can transfer electronic data. Accordingly, the performance of many computing tasks are distributed across a number of different computer systems and/or a number of different computing environments.
Software frameworks, such as Microsoft's .NET framework, are used to execute applications. Such frameworks consist of a runtime and a library. For example, the .NET framework consists of the Common Language Runtime (CLR) and a class library. The library in general implements common functionality that is made accessible to applications via application programming interfaces. When the runtime of a framework executes an application, it determines which portions of the framework's library are used by the application and loads those portions. In the .NET framework, these portions are referred to as assemblies. In this specification, the term assembly, however, is used generally to refer to an identifiable grouping of code that provides functionally that can be utilized by other code. Assembly can be equated with library within this specification. In this sense, a Java Archive (Jar) file can be considered an assembly.
When an application is designed to be executed on a particular framework, the application generally references assemblies available in the framework. When the application is executed on the framework, the referenced assemblies are loaded and executed as well. Because of this, it is desirable to protect the security of an assembly so that it can be ensured that the assembly has not been modified by anyone other than the publisher of the assembly.
One approach for securing an assembly is known as strong name signing and is depicted in computer architecture 100 in FIG. 1. An assembly 104 is signed with a strong name, generally at compile time, by the owner of the assembly (e.g. on computer system 101). To sign assembly 104 with a strong name, assembly 104 is given a unique identity that may comprise an identifier of the assembly (e.g. file name 104a, version 104b) and a public key 110a of a public/private key pair. In this specification, this public/private key pair is referred to as the identity public/private key pair.
A cryptographic digest of the contents 104d of the assembly is also generated. Then, a digital signature 105 of this digest is created using the identity private key of the identity public/private key pair. This digital signature 105 is stored within the assembly. Accordingly, a strong name comprises a unique identity of the assembly which includes the identity public key, and the digital signature of the digest using the identity private key.
Once signed with a strong name, these assemblies are made available for use by other software components (e.g. other assemblies 106, 107 executed within framework 111 on computer system 102). For example, one company may release a strong named assembly for use within the .NET framework. Whenever another assembly (e.g. assemblies 106, 107) that references the strong named assembly 104 is built, information about the strong named assembly (as well as any other assemblies referenced by the other assembly) is stored. For example, when an assembly for the .NET framework is built that references strong named assembly 104, information is added to a manifest (e.g. 106a) for the built assembly that identifies that the assembly references strong named assembly 104 (e.g. by including the filename 104a, version 104b, and public key 110a of the referenced assembly 104). This information is based on the identity of the strong named assembly.
Subsequently, when assembly 106 is executed within framework 111, the loader determines which assemblies to load based on the information in manifest 106a. In other words, the loader will use the stored identity to look for the strong named assembly 104. Before loading the strong named assembly, framework 111 will verify the identity of the strong named assembly (e.g. as a means to verify that the assembly has not been tampered with). This verification is done by extracting the identity public key from the identity of the assembly, using the identity public key to decrypt the digital signature of the digest, generating a cryptographic digest of the contents of the assembly, and comparing the decrypted digest to the generated digest. If the digests match, then it is known that the digital signature of the digest was generated using the identity private key, and the assembly will be loaded.
This approach works as long as the identity private key is kept secure and the algorithm used to sign the digest with the identity private key is not known. However, many identity private keys as well as the algorithms used to generate digital signatures with such identity private keys are no longer secure. For example, if a second party obtains a first party's private key, the second party can modify (e.g. add malicious code to) the first party's assemblies and resign them using the first party's private key. The modified assemblies would then appear as if they came from the first party. Of course, this problem could be addressed by the first party resigning the assemblies with a new and/or stronger identity private key and/or using a stronger algorithm. This approach, however, would change the identity of the assemblies and would therefore require rebuilding each assembly that references the assemblies (so that the manifest correctly identifies the assemblies). As can be seen, rebuilding each assembly is impractical especially given that many strong named assemblies are shared assemblies used by many applications.